Auditing context architecture
One aspect of applying context to auditing is determining what depth, or how many levels, of context to apply. As current day applications are far more complex than those of years past, some amount of support for multiple levels of context must be available.
OpenEdge auditing supplies four levels of context information. Figure 10–1 illustrates the various auditing context levels available within a running OpenEdge application. Keep in mind that not all context features must be applied to every auditing situation.
Database transaction context
As shown in Figure 10–1, at the lowest level exists the database transaction context. The database transaction context identifies all audit events that are related to a single client’s database transaction. The database transaction context’s scope is indirectly controlled by the client application’s database transaction. When the application starts a database transaction, all auditing records will be associated with that transaction until the application ends the transaction. This happens automatically within the database language clients and does not require additional application code.
Audit-event group
The next outer layer is the audit-event group. This is an auditing context whose scope has a beginning and an ending controlled by the application developer. The developer adds language statements to the application that identify exactly where and when to start an audit event group and where and when to end the audit event group. During that time, all recorded audit events will be associated with that audit event group context. Any one audit event group context can encompass zero or more database transaction contexts, and only one audit event group context can be active at one time within an application.
Application context
The next outer layer is the application context. This is also an auditing context whose scope has a beginning and an ending controlled by the application developer. The developer adds language statements to the application that identify exactly where and when to start an application context and where and when to end the application context. During that time, all recorded audit events will be associated with that application context. Any one application context can encompass zero or more audit event group contexts, and only one application context can be active at one time within an application.
User login session context
The outermost layer is the user login session context. This auditing context reflects a single client’s user login session. The scope of this auditing context is indirectly controlled by the OpenEdge application developer through the use of the Progress 4GL language’s client-principal object.
Each instance of a client-principal object represents exactly one user login session. When a client-principal object is finalized to signify the successful authentication of the user, the client session context is automatically started. When a client-principal object is ended to signify a user logout, the client session context is automatically ended. During the time that the user’s login session is set as the current user in the application, all the audit events recorded will be associated with that client session context. The application can have only one active client-principal object set as the current application user at any one point in time.
The illustrations provided here show a typical nesting and usage of auditing contexts. However, it is an illustration provided only in the interest of clarity. Because the application developer controls the scope of the contexts, either directly or indirectly, the relationships can be of any design. For instance, you can choose to nest client session context within an application context; or you might choose to reverse the roles of the audit event group and application contexts. Audit event groups are not necessarily within the application context; both are independent and can be the outer bracket.
The only relationship that cannot be changed is that the transaction context must always remain the innermost of all the auditing contexts. The behavior of the transaction context is under the complete control of the OpenEdge clients, and, therefore, does not require developer intervention to be consistently implemented.